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MBM$ in UTRAN 



1 Introduction 
1.1 General 

This document discusses the handBng of Multimedia Broadcast/Multicast 
Servfoe (MBMS) in the UTRAN. 

In the Rel99/ReM/Rel5 UTRAN, allmost all communication with the UE (User 
Equipment) is bassd on point-to-point (PTP) transmission: almost all 
transmission of user data by the UTRAN Is towards a specific UE. The only 
limited support the Rel99/Rel4/ Rel5 UTRAN has for polnt-tc^muttlpolnt (PTM) 
transmission concerns the low-bltrate Cell Broadcast Services. 

For the UTRAN, the main new functionality that needs be realised for 
MBMS concerns high bitrate PTM transmteslm. 

The main purpose of this document Is to serve as background for the stage2 
and stage 3 specification work In 3GPP. The stage 1 provided by SA1 can be 
found In the document 3GPP TS 22.148 "MBMS; Stag© 1". SA2 started the 
work with the document 3QPP TR 23.846 "MBMS Architecture and Functional 
description'' and now the stage 2 work Is documented in a corresponding 
3GPP Technteal Spedfloatton. RAN2 Is working on RAN reiiuliements which 
are documented In the document 3QPP TR 22.092 "Multimedia 
Broadcast/Multicast Service (MBMS); UTRAN/GERAN requirement^' and In 
the stage 3 specification 3GPP TS 25.348 "IntfoduoBon of Multimedia 
Broadoast/MuMcast Sen/lce (MBMS) in RAN". 

Chapter 2 discusses different MBMS trar^mlsslon altemativos for the UTRAN 
on the UTRAN radio interface Uu. 

Chapter 3 discusses up to what extend the CN needs to be aware of the 
transniisslon alternatives the UTRAN is using. 

Chapter 4 presents a number of signalling flows, addrssslng the main 
scenarios that may occur* 

Chapter 5 discusses possibilities with respect to product phasing when 
introducing MBMS In the Ericsson UTRAN. 

Chapters 6 and 7 look at more detailed aspecte of the Uu, lu and lur Interface 
respectively. 

Assumption 1,1s There Is no need to discern between multi-oast serv/ces 
and broadcast services in ffiis (tocument ^nce the handling ta bcXh types of 
sendees k identical tor the UTRAN. 
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Uu MBM8 Transmission alternatives 

Different alternatives can be identified regarding how to reAfise transmission 
of an MBMS service In the UTRAN on the Uu interface: 

1 ) FTP - only 

2) PTM - Continuous transmission 

3) PTM- Discontinuous transmission 

4) FTP or PTM - Discontinuous transmission 

Each of these alternatives Is de8crlt>ed In more detcdl In the next sections. 



2A 



2.2 



2.3 



Altematlvs1:PTP 

In this alternative, those UEs that wantio receive a certain MBMS service will 
receive the Information via point-to-point radio links. 

In the NAS-domaln. the UE Indicates It wants to receive a certain MBMS 
senrice. As a result, the CN establishes a normal RAB towards tMs specific 
UE which will carry the MBMS data. 

Since only polnt-to-point transmission Is used In this alternative there is no 
need to have the UTRAN aware that there are transnnissiona ongoing related 
to a broadcast/multicast service. 

Therefore this altemative will not be discussed further in this document 

Altsmative 2: PTM - Continuous tranemfssion 

In this altemative, Continuous PTM transmission of a certain MBMS sen/Ice is 
configured In certain service areas (cells). 

The PTM transmission Is In this attematlve Is not dependant on e.s. the user 
load In the concerning cell. 

This alternative is most suitable for MBMS service provisioning in areas 
where the iikelyhood of a significant number of Interested UEs is high. 

Alternative 3: PTM - Discontinuoue transmission 

In tfiis altemative, a certain MBMS service Is always using* Pl'M transmission. 

However only if there is at least one UE in a cell Interested in receiving the 
MBiy«S service, the PTM transmission will be turned on. If not a single UE In a 
cell IS Interested In a certain MBMS service, the concerning PTM transmission 
vm be switched off. 

Thus: 



• if IKMBMSx interested UFs) » 0 



• No MBMS transmteston 
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• If#(MBMSxlntereatedUE's)>0 PTM MBMS transmlaeten 

TWs alternative can be seen as an Intermediate sljep, taking away some of the 
disadvantages of aRernative 2 (no transmissfon when no UE Is receiving), but 
not providing the flexibilfty provided by alternative 4. 

Alternative 4: PTP or PTM - Discontinuous transmlatsion 

In this alternative, a certain MBMS sennce will be provided based on PTP 
transmission If the number of UE's that wants to receive this MBMS service In 
a epecffto cell is low. Only when the number of receiving UE's In a certain cell 
exceeds a certain threshold TRw<.>ptm, the UTRAN will switch to PTM 
transmission in that cell^ 

This behaviour Is reflected in the following expressions: 

• If »(MBMSx liwerested UE's) «= 0 «> No MBMS transmission 

• «TIVtiwim>#(MBMSx Interested UE8)>0 PTP MBMS transmission 

• If#(MBMSxlnterestsdUPs)>TRpipwMM => PTM MBMS transmbsfon : 

PTP transmission will always provide the most radio resource efficient 
tmnsmlssion In case only 1 UE in a cell is interested In a certain MBMS . 
service. 

Using a sensible value for TRptp<.>ptm» this aKemative will provide the most 
radio resource ^fident eolutlon compared to the other altemnUvee listed hers. 

TRFTP<->prM is assumed to have a typical value between 2 and 5. 



3 lu IMBRflS IVansmlssIon Modes 

Next quesBon Is up to what extend tiie Core Network needs to be aware of 
the different MBMS transmission alternatives that were described in the 
previous (hapten Is the choice of transmission alternative a UTRAN internal 
issue related to smartness of UTRAN Implementation, or is CN support 
needed for some these alternatives ? 

This question is important since it will directiy impact the lu interface between 
CN and UTRAN. 

3.1 ' Bacliground 

For this question to be answered, it Is important to distinguish between 2 roles 
an RNC can have in the UTRAN: 

CRNC: Controlling RNC. the Radio Network Controller that controls tiie 
radio resources In a certain cell. The CRNC Is also responsible fbr 
scheduling and control of the common channels on the Uu. 



^ The threshold for switching from PTP->PTM could be different from the threshold swItchSig f rem PTM->PTP In 
order to prevent frequent switching kietween PTP and PTM transmission. 
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SRNC: Serving RNC, the HNC that controls the communication with a 
certain UE. The SRNC Is responsible for scheduling and control of 
dedicated channels on the Uu, 

Whenever for a certain UE the CRNC and SRNC are differe nt, the CRNC and 
SRNC are intensonneeted via the lur interface. 

3.2 Tracking versus No-tracking 

Assumption 3.1: PolnUto-muMpoInt transmission In RAN will be reaJlsBd by 
using the FACH transport channel. Usage of the FACH tnmsport channel Is 
assumed to gA/e a good compromise between R99-lmpaci and radio 
efficiency. 

The FACH transport diannel Is a common channel for whic:h (power) control 
and scheduling are completely handled by the CRNC. 

Transmission altemativa 2 assumed a continuous PTM transmission. The 
UTRAN does not need to be aware of how many UEs are Interested in a 
specific MBM5 service In the cell, or stated differently: the UTRAN does not 
need to track (sbe aware of the cell the UE Is in) users which want to reoeh/e 
a certain MBMS. As a result, no Involvement of SRNC's Is required. 

This is different for alternatives 3 and 4. For these alternatives the UTRAN 
does need to be aware of the number of UE's that want to receive a certain 
MBMS service in a cell in order to switch on/off transmission (alternatives 
3&4) or switch between PTP and PTM transmission (alternative 4). In these 
alternatives, the UTBAN needs to be able to track UE's receiving a certain 
MBMS service. 

Assumption 3.2: In those cases where It Is necessary for the UTRAN to be 
awere of the number of users that want to receive a specific MBMS sen/ice, 
ff)e counting by the UTRAN wBI be based on: 

- UE-^pedttc RAS's established towartfo these UEit, and 

• Mobility monitoring based on Rel99 RRC connection related 
signalling. 

This approat^ Is assumed to minimise UE&UTRAN Imped vfHile still resulting 
In aoceptMe pertormance. 

Since it is the SRNC tiiat handles the lu signalling for a specKlo UE, and tt Is 
the SRNC that handles the RRC connection towards a speictfio UE, the CN 
needs to involve SRNC's in the MBMS handling for alternatives 3 and 4. Also 
CRNCs may be involved in this case since again the PTM transmission Is 
handled by tiie CRNC. 

Summarising the above, the CN needs to distinguish between 2 modes which 
are internally called MBMS Fbced- and MBMS Variable transmission modes: 

MBMS Rxed transmission mode: 

- CN only needs to {nfomn CRNCs of the cells con'esponding to a 
certain service area about a certain MBMS service); 



CN does not enable the UTRAN to track MBMS U£iers; 
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. UTRAN is only able to use transmission aitematK-a 2; 
MBMS Variable transmission mode: 

- CN needs to inform the SRNC of a UE ttiat wants to receive a 
spedRo MBMS s^ce; 

- CN enables UTRAN to tracic MBMS user^ 

- UTRAN is able to use transmission alternatives 3 and 4. 

Tiie relation between the transmission modes and the transnrdsslon 
alternatives is shown in figure 1 . 

iu: Tted Transnrdsslon IModeP 'VarfaUe Transrrdss Jon ModeT 



Uu: Ait2:PlM Continuous Alt.d: PTM IDlscontinuous Alt.4: PrP&PTM rasoonilnuous 
Figure 1: Iu Transmbston Mode <-> Uu Transmission Altemetlve mapping 



Since the traddng of a UE requires that UE to have an RRC conneofion, : 
transmission alternatives 3 and 4 can only be used towaids UEs In RRC 
Connected Mode, i-lowever since the UTRAN does not need to perfonm any 
UE tracking for alternative 2, in principle transnrission alternative 2 can be 
supported towards UEs in RRC Idle Mode^. 

When the consequences of figure 1 were discussed both int^nally and 
externally (3GPP), it vras considered unacceptable that usage of the variable 
transmission mode over iu would rule out the support of UEs In RRC Idle 
modOr E.g. if the UTf)AN detects certain areas In which there are always a 
sufficient number of UEs to justify PTM transmission, it should be possible for 
the UTRAN to use transmission alternative 2 in the concerning cells. UEs 
should be able to detect In a ceil If an RRC connsctior is required for 
receiving a specific MBMS servicei and talce the corresponding action. 

This results In an update of the mapping shown in figure 2: 

Iu: ''RxedTian&misaibnMod^ "Variable Transrrissloni^^oder 



Xhxi A!t2:PTMOorMbluoua Atta- I^TM Dfaoontinuous AIIA PTPS^IM Disconfinuous 
Figure 2: Updated Iu Transmission Mode <-> Transmission At. Mapping 




3.3 



Uu: Idle Mode <-> Connected Mode 




^ Assuming tfiat we can define a solution on the Uu» which enables UEs In RRC Idle Mode to find and receive the 
MBMS transmissions (see chapter 5). 



+46 8 7641514 



Him b raioiic* uliii iBy.viam 



Huvudfaxert Kosaon 

it is observed to be a problem to enable the CN to configure fixed PTM 
trariOTiiasion in certain areas, which can be used by UE:s in Idle-modei and 
also sdii aiiow the UTRAN to optimise the radio signalling efficiency and 
choose for fixed PTM transmission in certain cells. A solution is that |>y 
combining the usage of the fixed lu transmission mode and the lu varlsd^le 
transmission mode for one MBMS service, the CN can configure PTM 
transmission in certain areas and still the UTRAN can decide to use a fixed 
PTM In certain other areas (see figure 2). As a result, both the CN and 
UTRAN can take deoislone enabRng reception fn RRC idie-ntode. 

Note: Ailthough it Is assumed that the UTRAN does not need to differentiate 
between broadcast and multicast services (assumption still It will 
be likely that an MBMS broadcast senflce will only use the Tixed 
Transmission Mode" due to requirements related to availability for 
everybody without requiring any RRC connection. An MBMS muMcaat 
service could be mapped to either the Fixed transmisston mode or the 
Variable transmission mode. 

Example Signalling flows 

in this chapter we look at several signalling flows related "j6 MBIMS service 
establishment and UE mobility. 

MBMS Fixed Transmission Mode 
Acdvation 

The first example (figure 3) shows the simplest case In which the CN requests 
the UTRAN to provkie a fixed transmission of a ceitain MBMS senwe in a 
fixed area. 



I CRNC I 



i ON 



UPDP 



- MC adc^ess & (apn, IP Mull cm adtff) 

- Afoa B fiat of seivlctt sra&s 

- RAB atiribuito (BW, doIay» .. .} 

4. MBMS BgAftPtt PfiTAHLISH 



• MC address = (APNJP Mu fitastaddi)^ 
.-nA-(RNCIPQddrBw) 

- lu transport ass » (OTP TEIO, UDP port) 

S. MBMS figARER EaXA^LISH RlfSP 



^ a.8iartofPTMwonUu 



*TLAb (8GSN IP Address) 
- lu umport BBS s (OTP ire ID. UDP port) 



7- MBMS AenVATlQM RPaP 



Ffgim 3: Fbced Tmn&nte^n Motto Activation Gxample 



4.1.2 
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Step 1&2: These steps are transparent for the UTRAN, They are only there In 
the casd of an MBMS multicast service, not in the case of an MBMS 
broadcast sen/Ioe^ 

Step 3: When there is data to be transmitted the CN will initiate the IVIBIMS 
ACTIVATION REQ. Note that this could be quite some time after specific 
UE'e have sent an IGMP Join In case there was a longer period without any 
data transmission. 

Assumption 4.1: Currently it Is assumed that the oomblnatfon of (APN, IP 
MC ack/ress) ur}iquety identMes a certain MBMS senflce. The APN (DNS 
name Indudmg qperator and network Identifier, 30-40 bytee} is required since 
dlffersra networl^ (distent broadcast centres) may use me samo IP MC 
address. 

Drawback of tfi/s identiffcathn Is the size of both parameters whhh is quite 
large. It la aUII Invesggated If a shorter kloniity ^ould be used. 

Step 4: The RNC will Immediately Initiate the bearer establishment procedure 
if ft did not receive the data already. The RNC can sent this message to any 
SQSN it Knows. If no lu-flex Is configured, the RNC will only be aware of one 
SGSN. In case lu-flex Is configured, the RNC may Icnow multiple SGSN. In 
this case the RNC can sent the message to any SGSN H: knows, i.e. it is 
assumed that any SGSN the RNC knows is able to provkJe the data for any 
requested MBMS sen^ices. 

Step 6: From Step6| it is assumed that the UE on Hs own will be able to detect 
the MBMS sennco transmission in the concerning cells. If the UE has Joined 
the MBMS sennce and has received e.g. the conrect keys, It will be able to 
receive the MBMS sen/lce without any further CN or UTRAN support 
See chapter 6 for more details. 

De-Actlvation 

Figure 4 shows an example of the de-activation scenario for the fixed 
transmission case. 



I TBMT 



I GRNC 1 



^ &StooolPTMteonUu 



^ 1 , MBMS PgACmVATIQN HgQ 

^ -MOaddrmaiAPISLlFl 



I (APN, IF MuittcaR addr) 
-(MSt«0<dniuedlian8rrrssIoa Tiedar) 



3. MBMS BgARgR RELFASP BfTQ^ 



- MC ftdtfrew » (APN.IP KAillleavt addf) ^ 
• TLA a (RNC IP address) 
lu tianqpon HM A (Onp TBD, UDP port) 



^1 il,MBMaBEftftgRtt|g|gA,OP|^f^p 



■gLMHMSACnVATIQWREB 



4.2 
4^.1 



+46 8 7641514 

7nn3 -01- 0 8 

MBMS Variable Transmission Mode 

MBMS Variable Tranemlssion Mode - PTP example 

the next signalling flow example shows the CN requesting &n MBMS vaiiable 
transmis^n mode: 



I TBMT 1 I CRNC | 



7^ 



1Q. ffiirtof PTPttcn Ju. 



I SRNO I 



ailOMPilotn Request 



4> MBMS ATTACH RgQ 



• MC ukfTMB* (APN. IP Mmtta sftaifdr) 

a. MBMS ATTACH RFHP 



-TrmmlBslon • PTP Tk 



a. RADPUMK RgCQMHQUBATl^M ff^^ 



0. RADIO UNKR600NHGURAT1QM 



, 3,iFMutii8a$tidir 

- IMSl » US-IM89 (»^'ar{BblB iransmla^n r odO 
• AreasGfitofsaivtce areas 

- RAB attlbutea (ew. dafiy, ...) 



R MBMS BEARER ESTABUfih 

- MC Kfdiess - (APN jp Muffioa»t a 
-UA« (RNCIP 8(Me») 

- hi ttansport aaa - (OTP TBO. UDP poit) 



>(5G5NIPi 

^ lu tiani|»rt aaa (Grp TQD, UOP P019 



MBMS U3ER ACtrVATICM RPfiP 



f%rt/r$ 5; Varlablo Transmission Mode ActlvaUm PTP example 
Rdmarks on the cOfferent steps: 

Step 2: The IGMP Join Request has no oonfimnatlon at IQMP level, however 
will be confirmed with other NAS signalling (transparent to IJri'RAN), 

Assumption 4.8: For a certain MBMS sen/toe the CN will configure service 
areas where this service can be received or not Then what to do when the 
UE perUmns the Join in an area where the service will not lye provided ? Or 
what to do when the UE performed the Join In an area where me service will 
be provided, but then passes through an area where service Is not 
provided. 

Taking Into account me location where the UE is located will make the 
hantning of me IQMP join very complicated, e.g. In the moblilty case (moving 
out and in an area where the servica Is provided), the UE could, e.g., perform 
a new IGMP join. The simplest way out of mese problems Is to assume that 
me handling of the IGMP join Is decoupled from me fecf If me UE Is realty In 
an area where it can receive me sendee or not As a result, the UE might 
perform a suooesfuB IQMP Joh but stlB not get the sen^ data. It Is up to the 

* An MBMS broadcast service is expected not to be ciphered. Thetefbre the UE does not need tc receive any 
spectnc ice^. 
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CN to conffgure tho service areas such mat this Is an imlikely case. 
It needs to be farmer hveetlgated if mie approach Is acceptable. There might 
also a relaOon to Oiar^g. 

Step 4: Before eetabltshing the user plane over iu, the SRNO firet checks ff 
the CRNC wants to provide the MBMS-eervlce based on a PTM transmission. 
In this example, the CRNC Indicates tfiat It does not want to provide PTIM 
transmission for this MBMS sen4ce. 

Step 6: Assuming the SRNC does not provide the requested liABMS service to 
any UE yet It triggers a bearer establishment procedure. 

Step 8: The SRNC reconfigures the existing Rl^ in order to be able to handle 
the additional transmission. 

Stepll: After the transmission of the concerning MBMS service has started, 
the UTRAN confinms user spedflo activation to the CN. 

Assumption 4.3: Similarly to assumption we assume that the l/TRAN 
vrill accept the user acUvatlon Ind^endan^ of the locaUon of the US, he. 
even if me UE Is In an area where it will not receive the MBMS sen^e, still 
the acttvation can be completed succesfully. 

MBMS Variable Transmission Mode - PTM example 

It has been observed to be a problem how to arrange a bearer establishment 
on lu when the CN does not know to which RNC the bearer needs to be 
established. A solution is to Indicate the MBMS activation to the SRNC and 
have the UTRAN Initiate the bearer establishment over I u. 

Rgure 6 shows a second example of the variable transmission mode. 
Remarks on the different steps: 

Step 4: Before establishing the user plane over lu, the SRNC first checks if 
the CRNC wants to provide the MBMS-senrtce based on a PTM transmission. 
This is the case in this example, 

St^ 5: Since the CRNC does not provide the requested MBMS service to 
any UE yet it triggers a bearer establishment procedure. 

Step 0: After the transmission of the concerning MBMS service has started^ 
the UTRAN confirms user specific activation to the CN. 
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I TBm I I CHNC \ \ 8HNC 1 

1> PDPcontHKtacilmflon 



iT.StartofPTMtxonUu 



A MPM8 ATTACH R5Q 



-Ue-UlMMNTl 
• MCtffdiMBo(APN.lP 



R MBMS gEARER ESTABUSH fiSQ 
Me a(Mra» « (A^N.tP MuMqbbI 

•>7LA»(nNeiPaddk«n) 

-Hi omport ass - (GTP TBip, UDf port) 

MBMfi aPAPPft gfiYABLrSH RFSP 



-TIA- (8Q8N IP addresB) 
- tu tanspoft aoa s (GTP tE10« f DP p«t) 



B. MBMS ATTACH REBP 
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1 CN 



^ MBMBACTVATIOM 

^ . luir* ttrfffflnn a J 



- JMSl > Ue-IM5) <i^*Vaiiabla transmission r 

- Aim * list Of 8eiv«e mm 
' RAB oKritauttm if^N. dftty, . ..) 



rw<lo') 



Figure 6: Variable Transmission Mode Activation PTM examole 



Mobility scenarios 

As a result of the above there will be areas (cells) in which a UE is required to 
have an RRC connection when recehring MBMS Information (FTP or PTM 
transmisBlon corresponding to transmission altematlve 3&4) and areas where 
such an RRC connection is not required (PTM transmission conresponding to 
transmission altematlve 2). Then the question arises what happens In case of 
UE mobility between 2 cells whore this requirement is different for the 2 cells. 
The different cases are listed in the table below: 



Coming f rom\gofng to 


PTM RRC 
connection not 
reoulred 


PTM RRC 
connection 
reauired 


PTP (RRC 
connection 
required) 


PTM RRC conneeiion not 
reauhred. 


4.3.1 


4.3.3 


4.3.S 


PTM RRC connection 
rsQuIred 


4.3.2 


4.3.4 


4.3.7 


FTP (RRC connection 
roQulred^ 


4.3.6 


4.3.6 


4.3.e 



Tob^ 4. 1.: I^obiiity overview 

Table 4.1 indicates In which section that specific case te discussed. 

It is a problem how to switdi between two cells which use a different Uu 
transmission altematlve. M^nly two solutions are identified: Either the 
UTRAN or the UE is responsible for detecting PTM transmissions in a ceil 
where the UE moves. The proposed solution is a mixture: In Idle/PCH/FACH 
states, the UE has to detect the transmissions on its own. In CELUJ3CH 
state, it wfll be guided by the UTRAN. 
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4A.1 PTM RRC Connection not required -> PTM RRC Connection not required 

The UE shaB read ttie new broadcast biformation and ttne to the correct 
FACH. No UIBAN involvement Is required. 

4.3.2 PTM RRC Connection required -> PTM RRC Connection not required 

Whenever the UE has the RRC connection established for c^er reasons than 
only the MBMS service reception, e.g. for a speech call, the RRC connection 
will remain as normal 

The interesting case is what happens when the UE only has the RRC 
connection for enabling the reception of the MBMS servlci?. In this case no 
RB will have been established towards the UE (allthough a RAB exists), end 
only the SRBs ^1 be configured Figure 7 shows a possible signalling flow for 
this case: 

I SBNOH 



f Tewr I I CRNO I 



I.SIQNAUJNQ 

• GNdontatfia 
»777 



a. WBC CONNECTION RELBaSB ONfy 



4.IURBJAggWB0VIEST ^ 



S. lUflELBASg COMMAND 



6. lU HHUtAgeCOMPLgTB 



7. MBMS BEARER BSLfiASE REO ^ 

• MC address -(At'N.lf^MultiQmkAddr) ' 
. TIA « {RNO IP MIdmn) 

• lu ttHRspoit Bss ■ (0TFTE1 X MOP pori) 

. a. MBMS BEAHER RELBASg WgSF' 



Figure 7: Mobility: HRC connQctlon no longer required 
Remariis on the different steps: 

Step 1: Since the UE only has a signalling connection (and FHRC connection), 
the only thing that can be released Is the signalling connection. The 
SIGNALLING CONNECTION RELEASE INDICATION is currently only 
assumed to be needed for rare error cases (e.g. MSC restail with loss of UE 
context) but could probably be used In this case. It might be pref erabe to add 
a cause iE. 



2: Since the UE moves to RRC Idle mode, the SRN3 role no longer 
needs to be fulfill^ for this UE. Therefore the iU connection for this UE can 
be removed. 



Step 4: Note that as a result of this step, an SQSN might get data from a 
GGSN but does not have to deliver it to any RNC. 
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Step 7' If the SRNC no longer needs the corresponding bearer, a bearer 
release will be requested. Note that the CRNC la ofcourse still receiving the 



PTM RRC Connsdion not required •> PTM RRC Connecllon required 

In this case, a UE receiving the MBMS service In RRC Idle mode now detects 
that an RHC connection is required. This Is shown In the following figure B 
which assumes that although PTM transmission Is already ongoing In the cell 
to which the UE is mo\^g» still the UE is required to establish an RRC 

connection: 

I SRNC i i cN i 



1 T&MT i 1 CRNC 1 



1. RRC CONNeOTON RIQ 

.CauMo'm 



a. RRC coiwEcnoN senjp cmpi^ 



4. RRC MltlAL DIRECT TRANSFER {HP Smssssge) 



T.QpiginuatenrfPTMtt 



a. iti ^nailing oorniBctfon esttblWtmgn! 
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• MO address - i^PK rP Multicast addr) 

• 1M5I B U&IMSi (B^/ortaMa Iransmlsslon 

- Area a list of sorvloo araas 

- RA0 anribulM (BW. dtlay. 
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F^ure 8: MMIIty: RRC Gonnecaon again requirad 
Remarks on the different eteps: 

Step 1: The UE wfll initiate RRC Connection establishment. A new cause 
value might be reqiired. 

Stop 4: At this stage, the UE vidll need to contact the CN somehow to trigger 
tfie UE-spedfio IMBMS activation. One option would be to us$e a nonnal RAU 
for this. 

It Is tor further study whether an RA-update Is enough for this case (seems 
qufte limiting to mandate a RA-boundary at this place), or it a service request 
should be mandated. The UE might even sent a service request If it has sent 
an RA-update. It might be a posslblBty that tfite NAS message Indicates per 
MBMS sennce If an MBMS ACTIVATION REQ is needed or not, or the CW 
performs an Activation for all MBMS services ongoing towards this UE ? 

4.3.4 PTM RRC Connection required -> PTM RRC Connection required 

4.3.8 PTP RRC Connection rec{uired o PTM RRC Connedion not required 

In this case, the UE moves from a cell In which It has a PTF* connection to a 
cell in which the MBMS service is broadcasted and no RRC connection Is 
required. 
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The first question to be considered Is who (SRNC or UE) ishould detect that 
the BRC connection Is no longer required. 

SRNC-detection: ^ _ ^^..^ 

If ]t Is the SRNC, the SRNC will find It out by doing the atfeioh to the DRNC, 
and the DRNC telling the SRNC that It ie already providing the sendee with a 
PTM to the UE and that no RRC connecdon Is required. Then the SRNC can 
ten the UE that ft should etart to receive the MBMS ser/lce via the PTM 
transmission and release the FTP RAB and possibly the RRC connection. 

UE-detectlon: ^ ^ 

We assume that the UE will monitor the MBMS SIB even in GELL^DCH state. 
The UE deteols that flia RRC connection Is no longer required for this service, 
and tn'^ers the release of the RRC conne<^on. 

. These alternatives imply the following advantages and disadvantages: 

UE detection: 

+ simple for the UTRAN 

- additional capabilities for UE receiver (reception of broadcast in CELU)CH 
state) 

SRNC detection: 

•f Simpler from a UE point of view 

- SRNC needs to be MBMS sendee aware (not lu Rxed mode only) 

Aasumptlon aJSz Hero, It Is assumed that we go for the SRNC detection 
€3pUon fri order to avoM the UEcomple)dty. 

This assumption also impacts the scenario of a UE with a speech call moving 
Inbetweon cells where the MBMS sen/ice is transmitted with PTM 
transmission. It Is for further study whether the UE cTeteds the PTM 
transmisdon or whether the SRNC teila the UE about tL 

FTP RRC Connection required -> PTtA RRC Connection lequired 

Should be based on an RRC Reconfiguration under control ci UTRAN. 

PTM RRC Connection required -> PTP RRC Connection required 

Should be based on RRC Reconfiguration under control of UTRAN. 

PIM RRC Connection not required -> PTP RRC Connection required 

Similar to 4.3.3, but with estedbilshing a dedicated channel. 

PTP RRC Connection required -> PTP RRC Connection n^qulred 



This is almost the normal R99 mobiRty handflng In CELUJX^H state, the only 
difference being the DRNC Informing the SRNC fliat jt does not want to 
provide the MBMS service on ptm. 
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4.4 Switching between FTP and PTM transmission In one cell 

4.4.1 PTP->PTM transmission 

4.4.2 PTP->FrM transmission 

4.6 Other Issues 

4.5.1 Start/Stop of transmission 

S2-02332S Indloalsd procedures by which the CN oouW inform the UTRAN 
about tfie start or stopping of transmission. It seems clear that this signalling 
win ©Jdst between BMSC, QQSN and SGSN, It is supposed to trigger a 
release of the user plane resource while still keeping the MBMS contexts In 
the network so that an easy later continuation of the sen/Ice Is possible. 

Such procedures could be Introduced on lu now or could be seen as potential 
optimisations for later releases. 

If these procedures do not exist, the transmission stop would be mapped to a 
normal MBMS Deactivation procedure, the transmisston iStart to a MBMS 
Activation procedure. 

Note that the start/stop transmission coming from the BMSC Is not UE 
specific. It will always concern ail UEs receiving tWs MBMS sjervice. 

4.5.2 MBMS specific psging over lu 

Currently it Is assumed that the CN never has to perfom paging for UEs in 
order to have them receive MBMS related data: 

1 ) In the fixed transmission mode, there Is no UE specific signalling. 

2) In the variable transmission mode, the paging Is UE spedfte and using 
existing mechanism/identity. 

Note: Of course the UTRAN might have to page the UE/UBi in order to have 
it/lhem receive MBMS related Information. 



5 Product Phasing 

It Is expected that the functionality described In the previous chapters will not 
be Introduced all at onoe. Instead there will be a phased introduction. This 
chapter desorlbss different possible MBMS Implementation cptions . 

5.1 MBMS Implementation opUone 

The following possible MBMS Implementation options are discerned: 



^ Only the impismsntation cptions which are consldsrsd most sensible are described. 
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5.1.1 No MBMS support In UTRAM 

In thte step, the l/TRAN is not aware of any MBMS specWc functionality; a 
standard R99 UTRAN oan be used. MBMS sendees are provided based on 
normeJ PTP RAB's. 

Benefits: 

+ No UTRAN adaptations 

Drawbacks: 

- Only FTP eupport 

- On^ racepdon In RRC corrected mode. 

5.1.2 MBMS Fixed transmission mode 

in this step, only CRNCs are upgraded with MBMS fiinclion^ TTiey 
provide the MBMS eenrtce with a fixed PTM transmission (MBMS fixed 
transmission mode). In addition, MBMS senno^wlth an expend low 
number of Interested UPs can be handled wHh PTP Iransrnission (based on 
5.1.1 option). 

BenefitB: 

+ Umlted UTRAN Impact 

+ SRNC does not need to be MBMS aware 

+ FTM for MBMS sen/Ices with expected high number of receMng UEs 
+ PTP for MBMS sendees with expected low number of receiving UEs 
•I- Support of reception in RRC idle mode in PTM areas 

DFawbacks: 

-One MBMS service always PTP or always PTM 

. CN needs to estimate the expected average number of receiving UEs in 

case both PTP and PTM are used. 

6.1.3 MIBMS Variable transmission mode: (dls)eonttnuou8 PTlfl In confisured 



in this step, all UTRAN RNC's are upgraded to become MBMS aware, MBMS 
sen/Ices are provided based on PTM, but the transmission can be turned 
on/off based on nurfiber of receiving UEs. 

Benefits: . 

+ No unnecessary PTM transmlsa'on if no interested UE Is present. 

♦ Support of reception in RRC idle mode in PTM areas with continuous PTM 

transmission. 

Drawbacks: 

- All UTRAN RNCs (SRNCs and CRNCs) need to become MBMS aware 
. Only PTM support 



i 



03 01/08 ONS 10: OB l»A +•»» • 'w*-— 

H6 8 7641514 



• iiin, t riOIOIIl* Wl H>y.»M«n»f» 

7no3 -ot- 0 8 

Huvudfaxan Kcnwn 

5.1^ MBMS VariaUe tranamtoelon mod©: FTP + ooirtlnuous PTM In 
conflguvm areas 

In this step, an UTRAN RNC's are upgraded to become MBMS aware. An 
MBMS seiSoe can be provided based on FTP and/or PTM tfansmlssion. The 
PTM transmission Is confinupus In configured PTM areas. _ 

UoUJmbms services provided by either PTP or PTM In on-a cell based on 
BjQieetBd number of UEs In that cell _ . 

Tsu^ Of leoeptlon In RRC Idle mode In PTM areas with continuous PTM 

transmission 

_ /^i uThAN RNCs (SRMCs and CRNCs) need to become MBMS avware 

- Ho swAchIng between FTP and PTM in one cell 

5.1 .5 MBMS Variable transmission mode: fWI support 

In this step, all UTRAN RNC's are upgraded to become MBMS aware. MBMS 
sendees can use aD 3 transmission aftematlves mentioned m oh^ar 3. 

Benefits: ^. ^. . 

+ Most advanced solution witti respec* to radio eff laem^ 

+ Support of reception in RRC Idle mode in PTM areas with continuous PTM 

irarismission 

Drawbacks: 

- Most complex solution • 
5.1.8 Overview 

An overview on the main differences between the lmplemi»ntallon options Is 
shown In the followtng table: 







Supported Uu 
Transmlselon 
allemaiives 


PTP or PTM 

transmission In 
cells 
PTP 


PTM on/off 

switching In 
on© oefl . 
hLA. 


PTP/PTM 
switching 
in one cell 
N^. 


1 

2 


No MBMS SUDDOrt Ih UTHAN 
MBMS Fixed transmission mode 


1 


AH cells PTP or 
M cells PTM' 


No 


No 


3 


MBMS Variable transmission mode: 
(dis)cont!nuous PTM In eonfiauPBd areas 


2,3 


PTM 


Yes 




4 


MBMS Variable transmission moda: 

PTP continuous PTM In configured areas 




PTP or PTM 


No 


rSo 


5 


MBMS Variablo transmission mode: 

fuW support 


2,3.4 


PTP or PTM 


Yes 


ySs 



Table 6. 1: ImplentaBon opGon avavisw 

The table indicates which oharacterisfics the UTRAN wilt haw In a certain 
ImplementaOon optJon with respect to the handling of ads mbms service. 



* The current assumplton te that it will not be possible to have PTP<->PTM swHohing ^''^^^^^l,^^ 
ImptemeSon soluSon (so e.g. going from a ceil wlih PTP transmission to another cell wWh PTM transmission). 
However thte Issue is sdll under Investigation as part of assumptkm 4.5. 
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0 Uu aspects 

6.1 Requirements 

1) Whenever there to a PTM transmission for a certeh MBMS service X 
ongolna In a cell, a UE shall bo able to detect *hl8 transmtea^on and 
^ll?a Tlite both in RRC Idle mode and RRC Connected Mode. 
Recei>tion may depend on UE capabilities. 

2) Whenever there Is a PTM transmission for a certain MBMS seiyloe X 
ongoing in a cell, a UE shall be able to determine H It to required to 
establish an RRC connection In order to ensure the PTM transmission, or 
If no RRC connection Is required (RRC Idle mode supported). 

Assumption 5.1: It Is assumed that In case no PTM <»a^"»'ssto/i for a 
certain MBMS service X Is ongoing, nis not required to enable the UEto 
distinguish between a cell In vrhlch the MBMS service X Information can be 
provided oraoeU in which the MBMS service X cannot be provided. 

6.2 SelifOon description 

At least three <»fferent steps can be discerned In the MBMS related 
infomiatlon that needs to be sent over the Uu: 

1) Broadcast of configuration Infomiation regarding ongcang PTM MBMS 
data transmission 

2) PagingofUEs In case of actual data transfer 

3) Actual MBMS data transfer 

These three steps are described In more detail below. 

6.2.1 MBMS conflgurallon broadcast 

A new "MBMS SIB?" should probably be defined for this purpose. The MBMS 
SIB would contain for each MBMS service broadcasted In the ceW the 
following information: 

- IP MC address 

. Physical channel (S-CCPCH) related information 

- Transport channel (FACH) related Infonnatjon (FFS) 
_ Logical channel related Infonnation (FFS) 

- MC-RNTI (FFS) 

In general, this information should not be changed too lr€<|iient since SIB 
updating requires sending nodfleations to all UEs. 



■03 01/0* ONS 11:00 FAX +46 8 7e41»14 

H6 8 7641514 ln!LtPalBit-od)res.ve|i(i$ 

tm -01- 0 8 

ej^ paging of UEs In ca«i of aetual date transfer Huv«*faw» Itewn 

I le offinJant solution UEs shouW ttoi bs mandated to have to 
ongoing for the conoerNng MBMS seroice. 
Several ways exist to overcome such a problem In UTRAN: 

11 use of a fixed DTX scheme: Every MBMS sendee could only be djjwed = 
' H e»«rl ^n«mififiton at certain frame positions. A UE receiving this MBMS 
leS^ldhSrhSTtol^ nsteSSg atthese Instances. If noting Is 
flc^^^d^he^Le^g radi frame. Se UE can go to sleep again untill 
the n«<t possible scheduling occasion. 

9\ Use of Daolno- Inform the UE when to listen to the FACH channel by ; 
r^J Sf^^^gii The MBMS paging should be ^fl^^^'l^l^S^l \ 
Ks se^kTrha following alternatives for ngWng the current UE 
specific paging suitable for MBMS paging are Wentffied- 

1) Allocation of a RNTI per MBMS sendee i 

2) Usage of the 12 remaining bits on the PICH channel 

These alternatives need to be Investigated in more detail. 

S^Ui Actual data transfer 

The actual data transifer Is assume to be transported over the FACH channel ' 
and will be using a special MC-RNTI. 

How many and which logical channel will be used is still FFS, but ©.g. as for 
CBS, a CTCH logical channel could be used- 



7 lu aspects 

7.1 Requirements 

Based on the above. It should be clear thai when the CN wants to provide a 
S^n MBMsTXoe. It has to configure the UTRAN with Wtotw^^ 
^^n? ?. vSiteh seivi'ce areas this MBMS service should be pro>rf^ witfi a 
3^nsml88lon mode, and in which service areas the f ®f '^"'^^f®" 
S prodded with a variable transmh«lon "^^^^ JSl^Sjffi^^^^ 
the UTRAN for a specific MBMS servica will be UE independent 
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